Since there were *no* examples of writing a hardware driver using an LKM on OpenBSD, and there are plenty of examples of new ones being added to the static kernel, I don't think this in any way makes adding hardware drivers more difficult. To my knowledge over the last 16 years or so, the only real uses for LKMs have been kqemu (discontinued upstream) and dellflash (perhaps it works on laptops but it never worked on any poweredge which I tried it on). Note that neither of these are hardware drivers.

Some of the less-helpful "community" members could do with a kick up the arse though, better to not post than to post an RTFM without at least pointing out which bit of TFM to R. I'm sure that often they don't know the answer themselves. (Not to be mistaken with mails from time-starved people that are equally short but do actually point people in the right direction...)

Besides the "what if someone fucks with /dev/random" issues, there are problems like "what if the sysadmin forgets to create /dev/random in chroot" (ok, sysadmin failure but it can be protected against - and better to fail hard than fallback to a bad entropy source) and especially "what if an attacker holds open a bunch of FDs so opening /dev/random fails". This last one is perhaps the most worrying.

A bit ungainly, but that's necessary. Redhat tried to make it look neater and ended up with https://bugzilla.redhat.com/sh...

There is refutation from Jason; http://marc.info/?l=openbsd-tech&m=129244045916861&w=2

If you run FreeBSD, having PF ported gives you a more sane choice of firewall there, but if you're setting out specifically to run PF, OpenBSD gives some major benefits. The code is several years ahead of FreeBSD's port. Watch some of the recent presentations to see what's changed - see links to a couple of related videos at http://spacehopper.org/pfvids/